I want to know more about how/why Docker/Podman work with OpenShift. From my reading of the Basic auth handler in regclient the Basic auth only uses username/password credentials, never Token-based credentials. The Token-based credentials are only used with Bearer auth.

Digging way down into how Docker does auth, I see everything relies on what's parsed from the WWW-authenticate header from the registry - can you see what's in the WWW-authenticate header when you ping your OpenShift registry?

@baronfel I tried to keep this PR focused on something backportable to .NET 9 so we can have working auth against the OpenShift registry.

I'm also interested in understanding better how docker/podman work so we can align on their behavior. I assume that may mean a bigger (and riskier) change.

I want to know more about how/why Docker/Podman work with OpenShift. From my reading of the Basic auth handler in regclient the Basic auth only uses username/password credentials, never Token-based credentials. The Token-based credentials are only used with Bearer auth.

Not sure if this matters, the auth is stored as:

{
	"auths": {
		"default-route-openshift-image-registry.apps.sandbox-m3.1530.p1.openshiftapps.com": {
			"auth": "..."
		}
	}
}

And ... here is base64(username:password), and in this case username is the literal <token>.

can you see what's in the WWW-authenticate header when you ping your OpenShift registry?

It is:

www-authenticate: Bearer realm="https://default-route-openshift-image-registry.apps.sandbox-m3.1530.p1.openshiftapps.com/openshift/token"

The full response is:

< HTTP/1.1 401 
< content-type: application/json
< docker-distribution-api-version: registry/2.0
< www-authenticate: Bearer realm="https://default-route-openshift-image-registry.apps.sandbox-m3.1530.p1.openshiftapps.com/openshift/token"
< x-registry-supports-signatures: 1
< content-length: 87
< date: Wed, 11 Sep 2024 17:14:00 GMT
< set-cookie: 34727b82525eb26a530629c5bf0ec2f2=0e38c0640afce7f2163862707f60209e; path=/; HttpOnly; Secure; SameSite=None
< 
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

That WWW-Authenticate is literally asking us to use the Bearer scheme though. I'm very confused by this.

That WWW-Authenticate is literally asking us to use the Bearer scheme though. I'm very confused by this.

Me too. I'm going to try and figure out what podman does exactly.

I'm going to try and figure out what podman does exactly.

Here it is:

When the server responds with WWW-Authenticate: Bearer, the client is here: https://github.com/containers/image/blob/31d4ad14fe4da8ef3969ff67297831ab291c76f1/docker/docker_client.go#L744-L748

And in the getBearerToken branch, it responds with Authorization: Basic: https://github.com/containers/image/blob/31d4ad14fe4da8ef3969ff67297831ab291c76f1/docker/docker_client.go#L842.

I tried both podman and docker with the config mentioned in #43354 (comment) and both are responding with Basic.

Currently the PR adds the Basic auth as a fall back on the existing logic.
I assume this is desired for requesting a .NET 9 backport.

To align further with podman/docker we need to update the existing auth code (and try additional cases).

To align further with podman/docker we need to update the existing auth code (and try additional cases).

I'll take a closer look at this and make a separate PR so we know what those changes would be. I hope to find some time for it next week or the week after.

I'll take a closer look at this and make a separate PR so we know what those changes would be.

WIP: #43491

Closing in favor of #43491.